Telephony has advanced dramatically with the advancement of technology. Telephone communication was once limited to an analog public switched telephone network (PSTN), where the PSTN has been traditionally formed of two types of telephone carriers, local and long distance. The local carriers established local networks for subscribers to communicate within local regions, and the long distance carriers created networks between the local networks to enable subscribers of different local carriers to communicate with one another.
Over time, mobile telephone networks were developed to enable subscribers to use mobile telephones. At first, the wireless networks and handsets were analog. Technology for the wireless networks was developed to provide digital wireless communications, which provided a clearer signal than analog wireless communications.
About the same time that the digital wireless networks were developing, the Internet was also developing. The International Standards Organization (ISO) developed an Open Systems Interconnection (OSI) basic reference model in 1977 that currently includes seven different layers. Each of the layers provides protocols for certain types of operations. More specifically, the seven layers include: physical layer (Layer 1), data link layer (Layer 2), network layer (Layer 3), transport layer (Layer 4), session layer (Layer 5), presentation layer (Layer 6), and application layer (Layer 7). Each entity interacts directly with the layer immediately beneath it and provides facilities for use by the layer above it. The protocols on each layer enable entities to communicate with other entities on the same layer. The Internet initially provided for simple digital data to be communicated between users. One of the early communication application included email. However, as communications standards and protocols developed, the Internet matured to include more advanced communication applications, including voice over Internet protocol (VoIP).
FIG. 1 is an illustration of a legacy telecommunications network that includes class 4 and 5 switches 102a-102n (collectively 102) and 104a-104n (collectively 104), respectively, connected to a signaling system #7 (SS7) network 106 (indicated as dashed lines). Historically, the class 5 switches 104 were generally configured to communicate via in-band signaling verses the use of SS7 signaling and operate to form a local network of subscribers within the network to place telephone calls to one another. The class 4 switches 102 were developed for long distance connections between the class 5 switches 104 at end offices (not shown). The class 4 switches 102, which are monolithic, are generally formed of multiple components, including a port, port cross-connect matrix, switch messaging bus with external signaling units, and call processing unit, as understood in the art. Class 4 switches are circuit based and utilize time division multiplexing (TDM) and are capable of terminating higher high-speed communications, including T1, T3, OC-3, and other four-wire circuit connections. As understood in the art, TDM is a synchronous communications protocol.
The SS7 network 106, which includes signal transfer points (STPs) 108a-108n (collectively 108), service switching points (SSs) on the class 4 and class 5 switches, and service control points (SCPs—not shown). The SS7 network is connected to the class 4 and 5 switches for providing and maintaining inter-switch call services between the switches. The SS7 network is used to signal out-of-band call setup, as out-of-band signaling is more secure and faster than in-band signaling. The call state changes of the inter-switch trunks of the class 4 switch are communicated to the adjoining switches via the SS7 network via a connection to the STP. To manage and route calls, the STPs 108 are used as an Inter-Switch messaging network whereby two switches control the trunking between the switches via messaging over the SS7 network provided by the STP switches that act as the inter-switch message bus. A call state machine of the class 4 switch provides control for routing traffic within the cross-connect matrix of the monolithic switch. The call state machine also provides call control signaling information to other switches via the connections to the STPs. The call control signaling information is routed via the STPs to other switches for call setup and tear-down. The call control information routed by the STPs contains pertinent information about the call to allow the terminating switch to complete various calls.
Telephony has benefited from the development of the OSI model in a vast number of ways. One way has been through separating the call controller into a distributed cross-connect on an asynchronous network, such as asynchronous transfer mode (ATM) or a Internet Protocol (IP) network FIG. 2 is an illustration of a conventional telephony network 200 that includes a packet network 202. In one embodiment, the packet network 202 is an ATM network Media gateways (MGs) 204a-204n (collectively 204) are media translation or conversion devices that modify and convert protocols between disparate communication networks. The media gateways 204, which are in communication with class 5 switches 206a-206n (collectively 206) are located at the edge of the packet network 202. The media gateways 204 convert TDM packets or streams 208 into packets, frames, or cells (collectively referred to hereinafter as “packets”) 210 and vice versa.
The packet network 202 operates independently as a distributed virtual media gateway port cross-connect for voice calls primarily due to one or more call control managers (CCMs) 212 located on the packet network 202. The call control manager 212 is in communication with the media gateways 204 and operates to control the media gateways 204 and provide instructions on how to rotate the packets 210 via far-end address allocations. By separating the call controller from the class 4 switches, the packet network 202 becomes, in effect, the virtual cross-connect of the switching system. The packet network 202 enables packets 210 that include voice data, commonly known as bearer packets, to be tagged with a destination address 214a and origination address 214b for enabling content data 214c to be properly routed from the origination media gateway 204b to the destination media gateway 204a. The media gateways 204 use of the packet network 202 is controlled by the CCM 212 and may communicate the packets 210 over the packet network 202 via IP addresses and virtual circuit (VC) or virtual path (VP) between the media gateways 204 to appropriately route the packets to the correct destination network node through the packet network 202. CCM 212 receives call state processing information from the media gateways 204 and signaling points, and processes the call state changes by using look up tables (not shown). The CCM 212 thereafter communicates packet addressing and state changes to the media gateways 204 to process the call.
Ethernet protocol was developed to provide for a computer network that enables multiple computers to share a common external inter-communication bus. Ethernet is generally used to provide for local area networks (LANs). Ethernet operates by communicating frames of data. While Ethernet operates well within a local environment (e.g., within a building) because Ethernet assumes that there is an known capacity of bandwidth associated with the bus standards set forth in the IEEE 802.3 standard that defines Ethernet. Ethernet is a shared environment, where co-utilization creates transmission errors called collisions. These collisions are detected by Ethernet cards in computers and a random re-transmission timer is used to avoid the next collision. Ethernet poses special problems for use in communications systems given it lacks dedicated bandwidth and time slots. The shared nature of an Ethernet network creates additional complexities in that the amount of available bandwidth can vary when used with wireless technologies.
Communication protocols transmitted over packet networks, such as ATM or IP networks, may utilize TDM based transmission facilities, which are synchronous as compared to Ethernet transmission facilities, which are asynchronous. Synchronous transmission protocols utilize a common clock and channel schema so that each device on the network operates synchronously with a dedicated path. Two types of “connection” state knowledge are present in a dedicated system, such as a TDM. Each channel has a dedicated amount of bandwidth and an error rate that is calculated from a common clock to determine path errors. The two types of connection state awareness functionality are provided by the channel itself and the common clock and data within a TDM header. The common clock provides for a determination of (i) a communications data rate from one end-point to another end-point and (i) the data quality. Additionally, the TDM protocol includes “far end state” data in a header of a TDM frame to indicate whether there is a connection at the far end, thereby providing an indication of continuity along the communications path. Specifically, in-band end-to-end alarming allows the cross-connect devices to receive indications of continuity problems with other end-points. The in-band alarming is also provided for connection quality, where Bit Error Rate (BER) allows each end-point to know the quality of the data being received. Furthermore, bandwidth is always in use meaning that packets are synchronous, which that the far end knows exactly how many packets are to be sent and received in a given time period (e.g., one second). Computation of utilization is easily made by using the known bandwidth and multiplying it by the “seizure” time or the amount of time in use.
Packet-based communications sessions lack circuit based connection state awareness indicators and clocking functionality to provide a session controller the ability to know the path connectivity state to efficiently manage making call handling decisions with anything other than ample bandwidth to setup and use sessions. This lack of connection path state awareness with the communications protocols, such as Ethernet and Internet protocol (IP) technologies, result in “gaps” in terms of being able to react to decaying transmission path quality and be sensitive to shared use of bandwidth. Most IP call controller solutions are founded on enterprise applications, where a single entity owns the network and scale of the network is relatively small. IP and Ethernet protocols lack the in-band path signaling, quality and use metrics to allow for this scale, or the ability to perform enhanced call handling with paths outside the governance of the packet network. Because packet communications are asynchronous, there is no common clock, and, thus, there is no way to know how many packets were transmitted, which, in turn, removes the ability to characterize transmission quality of the entire path, the amount of bandwidth available, or the amount in use. Further, packet networks are “converged” meaning they have both real-time and non-real-time bandwidth use. Currently, there is no in-band mechanism for determining real-time and non-real-time bandwidth use; having such information would allow for handling calls. It is commonly understood that proper connection operational assumptions are made by call control engines when the SS7 signaling path is properly operating (e.g., provisioned bandwidth is available) between end-points within the SS7 network. These operational assumptions are problematic as Ethernet, IP, and other data networks become oversubscribed and cause the packet network to become congested and prevent throughput. In cases where an end-point, such as a WiFi telephone, is mobile and bandwidth changes with signal strength (e.g., a WiFi telephone losing bandwidth as an individual walks away from a connection point antenna), the connection operation assumptions also fail to provide graceful call handling.
One available technique in packet networks to prevent oversubscription of real-time media traffic is through the use of call admission control (CAC) or the IP equivalent known as Resource Reservation Protocol (RSVP). CAC is primarily used to prevent congestion in voice traffic and is applied in the call setup phase to ensure there is enough bandwidth for data flow by reserving resources. To reserve bandwidth through the entire packet network a CAC requires that the CAC procedure be performed at each point along a virtual circuit between two media gateways on which a call is to be routed, and often in a bi-directional fashion. While CAC functionality exists, the use of such CAC functionality is almost never applied because of the amount of time needed by the CAC procedure during call set up. For example, currently, CAC typically cannot operate over 40 calls per second and typical call set-ups on media gateways or class 4 switches may be 200 calls per second or higher.
One technique used to monitor the performance of IP session performance (i.e., after a call session has been established) is the use of the real-time control protocol (RTCP) as defined in IETF RFC 3550. RTCP collects statistics on a media connection, including bytes sent, packets sent, lost packets, jitter, feedback, and round trip delay. Other information may be provided in the RTCP packet using profile specific extensions. RTCP, which operates on a per session basis, is used for quality of service (QoS) reporting after termination of a session. The statistics information may be used, for example, to improve the quality of service by limiting data flow or changing CODEC compression. Utilization of the real-time QoS statistics, however, is limited to the specific session associated with the RTCP stream.
An emerging standard that is being developed for Ethernet performance measures is 802.1AG. This standard operates by generating and communicating an 802.1AG packet or “heart beat” over an Ethernet network segment. The 802.1AG packets are communicated via a Layer 2 Ethernet Virtual Circuit, such as a VLAN or Ethernet tunnel. At the ends and mid-points in Ethernet tunnels, 802.1AG packets are transmitted periodically over the Ethernet network to the far end. The Y.1731 protocol is utilized to calculate the number of data frames communicated between the 802.1AG packets. This configuration enables a performance measures (PM) to compute certain information about the performance of the path between the end-points on an Ethernet network. This combination of 802.1AG and Y.1731 enables the end points to be knowledgeable about the Frame Loss Rate (FLR), packet delay, and jitter in the path. This configuration is helpful to assist in monitoring performance of an Ethernet network path and diagnosing connectivity faults. However, the configuration falls short of providing the amount of real-time bandwidth in use or the total bandwidth in use. This information is useful to the proper management by a session controller handling calls during periods of flux in the packet transmission path, or the management of the real-time traffic.
Service providers often have trouble isolating and diagnosing network problems. To attempt to locate a packet loss problem along a node segment (i.e., a path between two network communications devices) over a network a probe that may be used to trace data packets being communicated over the node segment. This probe, however, is typically an external device from the network communications devices and operates to run a trace over an instant of time to determine network performance information, such as packet loss, jitter, and delay. An operator using the external probe may view results of a trace to diagnose the network communications problem. These results are not accessible to the network communications devices and cannot be accessed by network communications devices to alter network communications.
Telecommunications switching systems today provide for Internet protocol (IP) communications between two end-points within a network or a different network to be terminated to a far end-point. Calls between two end-points are routed to the terminating end-point based on the address input at the originator. This address information is then relayed to a Call Control Manager (CCM) that screens, translates, and routes the call to the terminating subscriber or to another network to be terminated at a far end subscribers end-point. The basic functionality of this process is widely known within the art and is used throughout telecommunications networks for voice calling.
Within the architecture of this switching system, calls to and from end-points are controlled by the CCM. The CCM may be located within a monolithic device in a TDM switch architecture or provided by an outboard computing device that controls the calls by using signaling that controls network based routing and switching devices located within the network. The latter device is known as soft-switch architecture.
The soft-switch architecture within an IP network controls call processing through use of signaling to and from the end devices and media gateways. One example of a protocol used for this IP signaling is Session Initiation Protocol (SIP). This protocol is currently used mainly with IP telephony, such as VoIP, and can be used as an access protocol between the end-user and the CCM and/or between the CCM of one network and the CCM of another network.
Another protocol used mainly between the CCM and a media gateway is the ITU-T H.248 protocol, commonly known as Megaco. This protocol is a control protocol that allows the CCM to control ingress and egress from/to the media gateway as calls are set up using a media gateway. Within a packet network framework, IP communications between two end-points (both access end-points and media gateways) are controlled by the signaling of the end-point to/from the CCM. The CCM provides authentication, screening, translations and routing based on information that is stored in the CCM and from the state of the end-points that the CCM controls.
Within the soft-switch architecture, call control can only be accomplished based on information possessed by the CCM or the on/off state of the devices that has an association with the CCM. While this configuration is fine in a static environment, packet networks are in a state of change at all times since the network itself can carry different types of information besides voice calls. One skilled in the art knows that a packet network is a converged network that can carry voice, data, and video all in a single path, and routing of calls within a packet network is not static and can vary significantly from call to call.
Because of packet network content communications variables, calls may encounter congestion and loss of voice quality based on latency, jitter, and packet loss. These content communications variables can affect any portion of a call at any time based on the network elements usage at the time of the call. Unlike a TDM system where dedicated channels and circuits are provided, the CCM only has control of it own end-points. Other end units may attempt calls, computers may send/receive data without talking to the CCM, and other devices may require bandwidth while the original call is progressing, thus causing voice quality problems for the participants. In addition to these basic gaps, many physical layer 1 systems that are poor in regulating bandwidth, are being used for transmission facilities. WiFi, EVDO, 4G (WiMax), DSL, and cable systems are all physical layer 1 technologies that demonstrate different bandwidth rates and management of their ability to modify available bandwidth as the Signal-to-Noise (SNR) ratios change.
Conventional soft-switching has not been designed to provide relief for callers when congestion, jitter or delay problems, such as those described above, are encountered. Since conventional CCMs can only determine call success based on connectivity to and from the calling parties, voice quality between two parties is not taken into consideration for call success.
Communication problems of in-band signals over packet networks are difficult to isolate. Currently, if a communication problem exists over a transmission path, there are few techniques to isolate the problem. One technique includes using an external probe to capture and decode packets, commonly know as a trace, traversing over a communications path to help isolate the problem. However, technicians generally only run the trace in response to a customer notifying a communications carrier of a communications problem. If a problem exists across packet networks operated by different carriers, a typical response by a carrier is to contact the other to determine if the other carrier can locate a problem in its network. In other words, locating an in-band communications problem over one or more packet networks is difficult as troubleshooting tools for such problems are limited to out-of-band performance metrics (PM) and are not available as in-band information via control or signaling paths.
A problem that exists with current implementations of telephony over packet networks is that a call control manager does not have information about the bearer path. Traditionally, there was a linkage between transmission path state and the monolithic switch that essentially owned one end of that path where the in-band signaling and line characteristics were available and was an integral part of the information used by the CCM for call processing. As demonstrated in current implementations of VoIP, without knowledge of the bearer path, the call control manager may establish calls that result in poor voice quality or call setup failure.
In addition, IP Service gateways, such as a broadband remote access server (BRAS), functions to limit, commonly known as traffic rate shaping, each customer's DSL traffic to their purchased speed. There is no end-to-end signaling, outside of the embedded TCP flow control mechanism, used to adjust the bursting to eliminate packet loss. Rate shaping is a statically forced bandwidth constraint that alters the nature of a transmission path in the packet networks. This shaping coupled with commonly shared or “over-subscribed” bandwidth normally associated with trunking facilities between networks results in unknown transmission path states between media gateways servicing VoIP and other real-time services, such as Video on Demand (VOD).
Traffic Quality of Service (QoS) management of packets is performed, where multiple flows aggregate into a smaller flows or channels. The application of Internet Protocol QoS is performed at the egress point where traffic is transmitted over a single link. Current traffic engines use the following information to make QOS traffic decisions. The decisions are assigning a Class of Service (CoS) and then acting upon that service to shape, restrict, or pass traffic to an egress point. The variables used to assign priority to traffic flows can be based on: entrance port (assign a whole port a CoS), virtual circuit in a port (assign a CoS to an Ethernet Virtual Circuit, LSP, etc.), priority bit marking of each packet (P bit), protocol type (assigning a CoS to specific types of packets or traffic), IP address and port (assigning a CoS to a whole IP address, or its port addresses), session identification (a HTTP, UDP, or other session addressed call), or otherwise. This priority marking information is used by service points, and shared links to implement QoS for the shared traffic flows. QoS and CoS types of information are made available at the point of aggregation where traffic management or QoS functions occur. However, the number of packets transmitted or lost in the packet stream elsewhere in the network is currently unavailable without the use of a session or path based protocol. These packet loss functions are generally not tracked by QoS mechanisms.
In current traffic rate shaping designs, the Internet may burst a packet stream to a DSL user when the packet network or Digital Subscriber Line Access Multiplexer (DSLAM) itself may not have sufficient bandwidth to accommodate the packet session. In a TCP-based session, the transmission rate is throttled down after packet loss is detected in the session. In VoIP, the packet loss is not counted by the use of Real Time Control Protocol (RTCP) signaling, but it is captured as the call progresses by the end points. RTCP, however, only considers performance of its own sessions and not the transmission path performance as a whole. In both cases, packets are sent over the packet network that get dropped in mid-path and will not make it to the customer premises equipment (CPE) and user. More importantly, there is no cross-session information about the packet loss and no whole path information available in-band.
Also, packet loss can be due to available bandwidth transmission rate fall-off, such as when a WiFi user walks away from a WiFi Access Point (AP) and loses RF signal strength, signal-to-noise ratio increases, or congestion increases due to many users concurrently accessing the AP. All of these types of conditions in the transmission paths can have severe impacts upon the ability to accomplish call processing and call management.
An Internet Service Provider (ISP) may provide different Internet connectivity speeds or data transfer rates based upon their service plans. For example, a user may purchase 1.5 Mbits/sec data transfer rate for a predetermined amount, such as 10 Mbits/sec data transfer rate or higher. In general, the transmission path is between the shared (trunked) BRAS resource and the DSLAM that is supplying. The normal amount of bandwidth consumption in the download direction from the network to the user is high as compared to the upstream direction. However, there is no correlated throttling mechanism in the IP web-server linked to user's ISP service plan that can be used to shape the packet transmissions. So, all of the network traffic is shaped at the BRAS typically based on the user's purchased data transfer rates. Depending upon network conditions, some of this traffic may not make it to the DSL user since the BRAS has no knowledge of the IP service path from itself to the customer.
A problem occurs when the BRAS does realize congestion on a packet network, where packets are being dropped due to insufficient bandwidth. Some packets could be dropped in the packet network or at an aggregation device somewhere in the packet network. Currently, there is little intelligence that recognizes the dropped packets in the packet network. In fact, packet networks are designed to discard traffic based on QoS markings. This problem is made worse because transporting packets that will ultimately be dropped adds to congesting the network. The packets consume bandwidth until dropped.
Transmission Control Protocol (TCP) was designed to work in a best-effort, packet store-and-forward environment characterized by the possibility of packet loss, packet disordering, and packet duplication. Packet loss can occur, for example, by a congested network element discarding a packet. Here, a microprocessor or memory of a network element may not have adequate capacity to address all packets routing into and out of the element. Packet disordering can occur, for example, by routing changes occurring during a transmission. Here, packets of TCP connection may be being arbitrarily transmitted partially over a low bandwidth terrestrial path and as routing table changes occur partially over a high bandwidth satellite path. Packet duplication can occur, for example, when two directly-connected network elements use a reliable link protocol and the link goes down after the receiver correctly receives a packet but before the transmitter receives an acknowledgement for the packet.
An embedded capability within TCP protocol is the TCP sliding window technique. The sliding window was developed and deployed as a flow control mechanism used to minimize the inefficiencies of packet-by-packet transmission. The sending of data between TCP enabled end-devices on a connection is accomplished using the sliding window technique. TCP requires that all transmitted data be acknowledged by the receiving host. The sliding windows method is a process by which multiple packets of data can be affirmed with a single acknowledgement.